Date: Wed, 13 Jul 94 04:30:04 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #147 To: tcp-group-digest TCP-Group Digest Wed, 13 Jul 94 Volume 94 : Issue 147 Today's Topics: Bit Regeneration v. DAMA KA9Q/Slip server Managing MSS and Window (2 msgs) Managing MSS and Window; IP encapsulation (2 msgs) Speed and Bit regenerators Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Tue, 12 Jul 1994 06:50:56 -0500 (CDT) From: ssampson@sabea-oc.af.mil (Steve Sampson) Subject: Bit Regeneration v. DAMA To: tcp-group@UCSD.EDU Barry Gm8SAU/Dc0HK writes: > As there is an increase in the use of DAMA (csma/cd) Digi's inc latest > flexnet 3.3a Is there any plans for inclusion to wampes the DAMA mode > in the ax25 layer Barry points out that bit regeneration and repeaters are a waste of resources. DAMA would provide the same capability on a half-duplex channel with very minor AX.25 protocol changes. I think the TNC coders (Kantronics, AEA) should make the mode available (DAMA=ON), and probably NOS should run it also (DOS, Linux). The argument that a router would be better than a repeater is off a bit, as it assumes the user wants to route. Some may just want to chat, or hook up with a (gulp) BBS... In this case the repeater attempts to solve the hidden node problem, but so could DAMA, for a lot less. -- Steve ------------------------------ Date: Tue, 12 Jul 94 13:35:44 CST From: "Jan Dolejs" Subject: KA9Q/Slip server To: tcp-group@ucsd.edu Hi, Operations on a dial-slip line in one of distributions of KA9Q-NOS (PA0GRI->N1BEE->CWRU->jandol) 1.Overview The aim of usage of this dial-slip line(in connection with a modem) was to realize running of networks(on Fig. 1). The aims we can divide into several groups: o the connection of an end-user to the faculty-network, possibly to the Internet, o the connection of sublocal Ethernet-network,e.g. Gymnazium for blind, any separated department of faculty, home network,etc. to the faculty network, possibly to the Internet. The basic idea was a software realizing the user connection to a services of faculty-network and Internet(e-mail,news,telnet,ftp,gopher,http....etc.) was undependent on a type of used line. +-----+ +-----+ +------+ | PC | .................. | PC | |Cisco |----> Internet +--+--+ +--+--+ +---+--+ | | | ------+----------------------+-------+--------------+-------- Faculty | Ethernet +---+--+ | +----+ | NOS | +-+ PC | +---|--+ | +----+ M | . +----+ ----|---- +------+ |Sublocal | PC +-----M-------/ \----M----+ NOS +--+Ethernet +----+ / \ +------+ | . . / Telephone \ | +----+ . ! network ! |-+ PC | +----+ \ / | +----+ | PC |-----M------\ / +----+ \----|----/ End users M | +--+--+ | NOS | +--+--+ | --+-------+----------+-- | | +-+-+ Sublocal +-+-+ |PC | ........... |PC | +---+ Ethernet +---+ Fig.1. The connection of a telephone network to a faculty network. 2.Phase diagram In the process of configuring,maintaining and terminating the dial-slip line, the dial-slip line goes through several distinct phases: Attach asy .. Start slipsv .. | | Dialer .. | | | +-+-------+ +-+------+--+ +--------------+ |Dead | UP |Establish | OPENED |Authentication| | +---->+ +--------------->| | |---------| |-----------| |--------------| | Closed | |Listen | |Opened | +----+----+ +----+--+---+ +--+---+-------+ ^ Fail/Stop | ^ DOWN Fail | |Success +<--------------+ | +------+ | | | | | | +-------+---+ | +------+-------+ | Stop |Terminate | CLOSING | |Network | +----------+ +<-----------+---+ | |-----------| |--------------| |Closing | |Open user/gate| +-----------+ +--------------+ Fig.2. Phase diagram This phase diagram is realized by several processes: slip server(slipsv) and dialer, and in the phase Network bootp daemon too. 3.Link Dead This phase begins with the command Attach asy .....(with parameters).Note that argv[8] must be "d".From this moment circuits(8250,16450,16550) and interrupt handlers(in,out processes and buffer) are initialised and the input process for SLIP line is suspend.The output process is saved in memory and new output process discards output data.The process responding on change of modem(RLSD) signal is not started too. 4.Link establishment phase The precondition for establishing of line is -so called- pasive open line (LISTEN).Process Slip server(start slipsv ifacename) realizes this function. From this moment, dial-slip line is ready for all changes,done by opening of line. That could be: change of modem signal(RLSD) or an activity of administrator or operator(starting of process dialer..).The process slip server carries out its immer initialization and waits for RLSD change(to state moved_up).The process dialer...(with parameters) carries out its synchronization with the process slip server and it does an usual service for modem and its translation to data mode. This process holds the line active(option automatical redial) without data discarding. 5.Authentication phase This phase is necessary.It's choosen a simple format for communication between both ends of line(like in communication with modem in command mode is always necessary return[\r] on the end of line.This simple communication protocol starts in moment, when both modems are already in data mode.The slip server requires the communication after the following scheme(Fig.3). server client | RLSD in moved_up | |<--------------- | | | | Verification | +----------------> | | | | Username: | +----------------> | | | | uuuuuuu\r | | <------------------+ | Password: | +----------------> | | xxxxxxx\r | | <------------------+ | | | slip-server> or | | Access denied | +----------------> | | SLIP\r | | <-----------------+ | | | MTU= | +----------------> | | | | | | | Fig.3. Authentication protocol The authentication of line runs by data in file slipuser. The format of line in this file is similar to format in popusers. Format: ifacename:Username:Password:Ustype:filterup:filterdn:Uslimit: where: ifacename ..............name of asy interface Username ...............user Password ...............password of user Ustype ...............type of user("b" user used bootp, "a" user not used bootp, "g" slip-gate) filterup,filterdn.......files with commands for configuration of IP-filter, filterup is done by opening of line and filterdn by termination of line, Uslimit ...............time limit for user. Tab.1. The usage of individual data in the file slipuser, in dependence on user type and type of getting of IP address. +--------------------+------+-----+-----+--------+---------+-------+ | User type |iface |User |Pass |filterup|filterdn |Uslimit| |--------------------|------|-----|-----|--------|---------|-------| |b |Open user |bootp| x | x | x | x | x | x | |---| |-----|------|-----|-----|--------|---------|-------| |a | |adm | x | x | x | x | x | x | |---|----------|-----|------|-----|-----|--------|---------|-------| | g |Open gate |adm | x | x | x | - | - | - | +---+----------+-----+------+-----+-----+--------+---------+-------+ x .... used - .... not used 6.Network layer protocol phase If authentication is OK,the line passes to state Network.The usage of IP protocol is assumed.In this moment we can distinguish following cases: o The end user opened the line and it uses BOOTP protocol for assignment of IP address, o The end user opened the line and it does not use BOOTP protocol for assignment of IP address, o The dial-slip gateway opened the line. In the first case, the BOOTP server assigns IP address by interface name of serial line(name asy interface).The slip server fills in(automatically) routing and arp tables and it uses filters(executes bootp daemon). In the second case, the network administrator answers the purpose for assignment of IP addresss.He must fill in manually data in routing and arp tables. The slip server executes the usage of filter. In the third case, the network administrator answers the purpose for setting of routing and arp tables in both dial-slip gateways. 7.Link termination phase The dial-slip line can be terminated in any moment, by falling down of line or by operator.Both ends of line find termination, based on change of modem signal(RLSD to moved_down). The proper termination of line should be carried out by that end of line,which opened the line(i.e. in case slip-gate:the process dialer or in case end user:software phone,umslip etc.).In case user type "g" are the same systems in both ends(NOS, which work contemporarily as server and client).It makes no difference, what system starts opening of line(proces dialer).The NOS system, opening line must hold the line(automatical redial) and must do the proper termination of line. Note:Further information and the distribution(binary) of this software is available for anonymous by FTP on: mbox.fsv.cuni.cz(192.108.140.149) /pub/nos jan.fsv.cuni.cz(192.108.140.148) /pub/nos ------ Jan Dolejs,Charles University,Prague,Czech Republic e-mail:jandol@mbox.fsv.cuni.cz jandol@jan.fsv.cuni.cz ------------------------------ Date: Tue, 12 Jul 1994 21:22:20 -0500 (CDT) From: ssampson@sabea-oc.af.mil (Steve Sampson) Subject: Managing MSS and Window To: tcp-group@UCSD.EDU In discussing MTU/MSS I put together this list. Maybe others will want to comment on it. The only thing I left out is NOS Segmentation (which won't work over Net/Rom) and the fact that MSS should be 40 less than the *Maximum* MTU. In this case I was tuning it for radio. If you have an Ethernet, I guess that the MTU would be 1500, and MSS will then be 1460, and thus when talking through an AX.25 to another system with both radio and Ethernet the two will agree on a 1460 MSS?? Problem there... Sorry if this was beat to death in a previous thread. ------------------------------------------------------------------------------- This assumes a dependable RF circuit Paclen 256 Not used in datagram mode. Example 1200 baud DG or VC: MTU 256 TCP MSS 216 MTU - 40 40 for IP header TCP Window 864 MSS * 4 Example 1200 baud over Net/Rom VC: MTU 236 PACLEN - 20 20 for Net/Rom header TCP MSS 196 MTU - 40 40 for IP header TCP Window 392 MSS * 2 (memory may be problem on Net/Rom) 9600 baud DG or VC over AX.25: MTU 512 TCP MSS 472 MTU - 40 TCP Window 1888 MSS * 4 -- Steve, N5OWK ------------------------------ Date: Tue, 12 Jul 1994 21:32:25 -0500 (CDT) From: ssampson@sabea-oc.af.mil (Steve Sampson) Subject: Managing MSS and Window To: tcp-group@UCSD.EDU In discussing MTU/MSS I put together this list. Maybe others will want to comment on it. The only thing I left out is NOS Segmentation (which won't work over Net/Rom) and the fact that MSS should be 40 less than the *Maximum* MTU. In this case I was tuning it for radio. If you have an Ethernet, I guess that the MTU would be 1500, and MSS will then be 1460, and thus when talking through an AX.25 to another system with both radio and Ethernet the two will agree on a 1460 MSS?? Problem there... Sorry if this was beat to death in a previous thread. ------------------------------------------------------------------------------- This assumes a dependable RF circuit Paclen 256 Not used in datagram mode. Example 1200 baud DG or VC: MTU 256 TCP MSS 216 MTU - 40 40 for IP header TCP Window 864 MSS * 4 Example 1200 baud over Net/Rom VC: MTU 236 PACLEN - 20 20 for Net/Rom header TCP MSS 196 MTU - 40 40 for IP header TCP Window 392 MSS * 2 (memory may be problem on Net/Rom) 9600 baud DG or VC over AX.25: MTU 512 TCP MSS 472 MTU - 40 TCP Window 1888 MSS * 4 -- Steve, N5OWK ------------------------------ Date: Wed, 13 Jul 1994 01:14:57 -0700 From: Phil Karn Subject: Managing MSS and Window; IP encapsulation To: ssampson@sabea-oc.af.mil FYI, I'm probably going to implement Path MTU Discovery in my TCP fairly soon. By the way, I'd like to survey the NOS variants out there that people are using to build their wormholes. When I originally wrote that code, I used IP protocol number 94 to mean "IP on top of IP". I later discovered that that protocol number normally implies something a little different, and the preferred protocol number for IP directly on top of IP is 4. It's used for multicast backbone tunneling, among other things. Some time ago I redid the receive routine so that NOS would accept incoming tunneled packets with either PID (4 or 94). The idea was to get that disseminated so that I could eventually switch the encapsulating side over to PID 4 without invoking a flag day. Can people tell me whether the receive-side change has made it yet to the NOS variants that people are using as wormhole gateways? Or do I need to keep 94 on the transmit end a little longer to avoid compatibility problems? Phil ------------------------------ Date: Wed, 13 Jul 1994 10:39:38 +0200 (BST) From: A.Cox@swansea.ac.uk (Alan Cox) Subject: Managing MSS and Window; IP encapsulation To: karn@qualcomm.com (Phil Karn) > FYI, I'm probably going to implement Path MTU Discovery in my TCP > fairly soon. In the light of SIPP/TUBA and the IPng stuff is this actually worth doing, especially given the number of places it breaks and the number of sites behind gateways that just do not cope with MTU discovery ? Alan ------------------------------ Date: Tue, 12 Jul 1994 08:16:43 -0500 From: rush@dns.sprintcorp.com Subject: Speed and Bit regenerators To: "Milton D. Miller II" Milton: I got another reply from my comments about the bit regen, which pointed out the hidden transmitter bugaboo. I was familiar with that problem, but I hadn't considered how the bit regen would have an advantage in such a case. But I would still prefer a cross-frequency solution... but that's obviously more expensive :-( Thanks for the note. David, rush@erg.sri.com, david@n0oxh.ampr.org ------------------------------ End of TCP-Group Digest V94 #147 ******************************